chore: add workflow for stale prs and issue type bug#2580
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds a new GitHub Actions workflow "Stale Issues and PRs" that runs daily (02:00 UTC) or manually, marking issues and pull requests stale after 30 days and closing them after a further 7 days, with separate jobs for bug issues and PRs and an operations cap of 500 per job. Changes
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/stale.yml:
- Around line 17-37: The stale workflow is unintentionally processing the
opposite item type because the action defaults unset PR/issue params to 60 days;
update the job that targets issues to disable PR handling by setting
days-before-pr-stale: -1 and days-before-pr-close: -1, and update the stale-prs
job to disable issue handling by setting days-before-issue-stale: -1 and
days-before-issue-close: -1 so each job only processes its intended item type
(refer to the input names days-before-pr-stale, days-before-pr-close,
days-before-issue-stale, days-before-issue-close and the job identifier
stale-prs).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 93b28aff-d8ef-4837-80ed-03bfa49e2d76
📒 Files selected for processing (1)
.github/workflows/stale.yml
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/stale.yml (1)
25-26: Using the same label forstale-*-labelandclose-*-labelis unusual.Both
stale-issue-labelandclose-issue-label(and likewise for PRs) are set to'stale'. Theclose-*-labelis applied when the item is closed by the action, so reusing the stale label makes it impossible to distinguish items that were auto-closed from those merely marked stale. Consider a distinct label such as'closed-stale', or omitclose-*-labelentirely if no close-time label is desired.Also applies to: 39-40
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/stale.yml around lines 25 - 26, The workflow currently sets the same label for stale and closed items (stale-issue-label and close-issue-label, and likewise stale-pr-label and close-pr-label), which prevents distinguishing auto-closed items from merely marked stale; update the action config by giving close-issue-label and close-pr-label a distinct label (e.g., 'closed-stale') or remove the close-*-label entries entirely if you don't want a close-time label, making sure to update the values for stale-issue-label, close-issue-label, stale-pr-label, and close-pr-label accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/stale.yml:
- Around line 25-26: The workflow currently sets the same label for stale and
closed items (stale-issue-label and close-issue-label, and likewise
stale-pr-label and close-pr-label), which prevents distinguishing auto-closed
items from merely marked stale; update the action config by giving
close-issue-label and close-pr-label a distinct label (e.g., 'closed-stale') or
remove the close-*-label entries entirely if you don't want a close-time label,
making sure to update the values for stale-issue-label, close-issue-label,
stale-pr-label, and close-pr-label accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bad684d4-53e1-4144-a3b5-031a50905922
📒 Files selected for processing (1)
.github/workflows/stale.yml
|
Leaving trace here of what I said in the chat, too, that my personal preference is to only do this for PRs (I would probably have 3 months instead of 1), and in the case of bugs only add the stale label but avoid the comment and auto-close. But I'm not doing a lot in the repo side, so I'll let you decide what works best for you. Thanks for modifying the previous version @MatteoGabriele! It is great that features are left untouched 🙏🏼 |
|
@patak-cat We're not going to leave any comments at any stage: this is just a stale tag after 1 month, then it closes after another 7 days, and it's always possible to reopen, obviously. |
4 participants
🧭 Context
We need an automated system to manage stale issues and PRs to keep the project clean. ✨
We have decided to focus only on "Bug" issues, as they typically have a shorter lifespan, along with all PRs. These will be tagged and then automatically closed.
📚 Description
These changes add the built-in GitHub stale action to automate the entire stale-tagging process and auto-close.
Issues of type "Bug" and PRs will be tagged after 30 days of inactivity and then automatically closed 7 days later.